home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 496 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. From: thp@cs.ucr.edu (Tom Payne)
  2. Message-ID: <4fu1kp$ifs@galaxy.ucr.edu>
  3. X-Original-Date: 15 Feb 1996 01:18:17 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 15 Feb 96 12:04:30 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Return-Path: <daemon@meeker.UCAR.EDU>
  8. Newsgroups: comp.std.c++
  9. Subject: Re: Throwing an exception from within a signal handler
  10. Organization: University of California, Riverside Department of Computer Science
  11. References: <4f2th6$4qh@galaxy.ucr.edu> <DMH620.FKn@falcon.daytonoh.attgis.com>
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMSMhWeEDnX0m9pzZAQF+KQF/bec8gv9SND/j44gJ0bgEB0mt0prkZUSK
  15.     +y0GKcXZenhBdkewJ1F3BsleOlMwffVe
  16.     =haKb
  17.  
  18. Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
  19. : > ==========Tom Payne, 2/4/96==========
  20. : > In the case of nonatomic
  21. : > variables, atomicity must be enforced by blocking certain signals.
  22. : > Such blockage could be portably implemented via atomic blockage flags,
  23. : > which, in turn, are volatile atomic variables that must be read by
  24. : > signal handers.
  25. : 
  26. : Although that could keep them from reading a bad value,
  27. : they have no way to wait for it to become valid if they
  28. : interrupted the owner. So, the updater thread would have
  29. : to fully block the signals that really need the value in the
  30. : handler for handling to proceed.  That is, the problems
  31. : are more severe than between threads that do not interrupt
  32. : each other (a signal handler is just a specialized thread,
  33. : whether or not the environment's terminology calls it that
  34. : is irrelevant).
  35.  
  36. The issues are the same as in any concurrent programming: 
  37.  
  38.   You've got protect critical data with locks, and you must block 
  39.   an interrupt (signal) whenever you hold a lock that its handler 
  40.   might attempt to acquire.
  41.  
  42. The locks and blockage mechanisms must be atomic, but not the data
  43. they protect (which de-facto is subject to atomic access only).
  44.  
  45. Atomicity issues aside, the multithreaded context is probably the
  46. correct one in which to consider the semantics for exceptions thrown
  47. by signal handlers.  For instance, which thread should catch such an
  48. exception?  The interrupted thread is sort of a hapless victim, and
  49. there's no reason to expect it to be prepared to handle the exception.
  50. If we let the throwing handler designate the catcher, we have a form
  51. of pre-emptive message passing, where the message-receiver function
  52. rethrows the exception in the context of the cathcher thread.  This
  53. may make some of the problems easier, if the invocation of the
  54. receiver can be made to occurr at conventient times, e.g., when the
  55. stack is tidy.
  56.  
  57. Tom Payne
  58. ---
  59. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  60.   Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  61.   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  62.